perf(array): add dense fast path to Array.prototype.push

Description

Array.prototype.push goes through the generic [[Set]] path for every element — converting the index to a PropertyKey, cloning the receiver, calling __get_own_property__, then __define_own_property__ with full descriptor validation. For dense arrays, none of this is necessary.

The PushValueToArray opcode (used for array literals like [1, 2, 3]) already has a fast path that appends directly to dense indexed storage via push_dense(). This PR applies the same pattern to the Array.prototype.push builtin.

How it works

Before entering the generic [[Set]] loop, check if the object is an extensible array with dense storage. If so, push each element directly via push_dense() and update the length in-place. push_dense() handles type transitions (DenseI32 → DenseF64 → DenseElement) internally and only returns false for already-sparse storage, so the first push serves as a probe — if it succeeds, all subsequent pushes are guaranteed to succeed.

The fast path is skipped for:

• Non-array objects (array-like objects go through the slow path)
• Non-extensible arrays (Object.preventExtensions, Object.freeze, Object.seal)
• Sparse arrays (storage already transitioned to sparse)
• Arrays whose length doesn't fit in i32

The slow path is completely untouched.

Benchmark results

Criterion microbenchmark (200 iterations × 5000 integer pushes):

Baseline (3 runs):          127.48 ms median
With fast path (3 runs):     64.73 ms median

This is a push-dominated benchmark. On a more realistic workload (pushing objects + filtering), the improvement is smaller since push is no longer the bottleneck:

Realistic (objects + filter, Date.now(), release build):
  Baseline:    139 ms median
  With patch:  110 ms median

Improvement ranges from ~20% (mixed workloads) to ~49% (push-dominated) depending on how much time is spent in push.